-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add consumer_lag in Kafka consumergroup metricset #14822
Conversation
Signed-off-by: chrismark <[email protected]>
Signed-off-by: chrismark <[email protected]>
Signed-off-by: chrismark <[email protected]>
Signed-off-by: chrismark <[email protected]>
Signed-off-by: chrismark <[email protected]>
Signed-off-by: chrismark <[email protected]>
Signed-off-by: chrismark <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ChrsMark thanks for taking this! I think that this solves one of the main issues we had with this module. We can decide in future PRs if we could further refactor this to have a single client, but I think that we still need to connect to non-leaders to monitor certain things.
Could you also take a look to the dashboard? The consumer lag visualization can be surely simplified with this new field 🙂
metricbeat/module/kafka/broker.go
Outdated
@@ -270,6 +280,15 @@ func (b *Broker) FetchGroupOffsets(group string, partitions map[string][]int32) | |||
return b.broker.FetchOffset(requ) | |||
} | |||
|
|||
// GetPartitionOffsetFromTheLeader fetches the OffsetNewest from the leader. | |||
func (b *Broker) GetPartitionOffsetFromTheLeader(topic string, partitionID int32) (int64, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit. Use Fetch
for consistency with other methods here.
func (b *Broker) GetPartitionOffsetFromTheLeader(topic string, partitionID int32) (int64, error) { | |
func (b *Broker) FetchPartitionOffsetFromTheLeader(topic string, partitionID int32) (int64, error) { |
@@ -68,35 +68,35 @@ func TestFetchGroupInfo(t *testing.T) { | |||
expected: []common.MapStr{ | |||
testEvent("group1", "topic1", 0, common.MapStr{ | |||
"client": clientMeta(0), | |||
"offset": int64(10), | |||
"offset": int64(10), "consumer_lag": int64(42) - int64(10), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit.
"offset": int64(10), "consumer_lag": int64(42) - int64(10), | |
"offset": int64(10), | |
"consumer_lag": int64(42) - int64(10), |
metricbeat/module/kafka/broker.go
Outdated
@@ -134,6 +137,13 @@ func (b *Broker) Connect() error { | |||
debugf("found matching broker %v with id %v", other.Addr(), other.ID()) | |||
b.id = other.ID() | |||
b.advertisedAddr = other.Addr() | |||
|
|||
c, err := getClusteWideClient(b.Addr(), b.cfg) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking that we could use this client for everything, but not, we may still need to fetch offsets from non-leader partition replicas for monitoring purpouses.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Though we can also use client.Leader(topic, partitionID)
for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 on revisiting this in a followup PR with refactoring purpose
@@ -113,12 +114,22 @@ func fetchGroupInfo( | |||
|
|||
for topic, partitions := range ret.off.Blocks { | |||
for partition, info := range partitions { | |||
partitionOffset, err := getPartitionOffsetFromTheLeader(b, topic, partition) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something to explore here.
I guess that it may happen that the partition offset here is always going to be ahead of the group offset, because we get first the group offset, and then the partition offset. Between both operations the partition offset may have changed.
Starting on version 4 of ListOffsets
(the API method used to get partition offsets), it is possible to indicate a current_leader_epoch
to retrieve "old" metadata.
Starting on version 5 of OffsetFetch
(the API method used to get consumer group offsets), its response contains a leader_epoch
field.
I wonder if we can use the leader_epoch
contained in the response of OffsetFetch
when available to query for the offset of the partition in the same epoch. This way we could have a more accurate value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are the implications for the support matrix? I'm not very familiar with API version vs Kafka versioning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are the implications for the support matrix? I'm not very familiar with API version vs Kafka versioning.
All messages in kafka protocol are versioned, each client and broker can support a different range of versions for each message. There is a message (ApiVersionsRequest
) to query the versions supported by the broker, we could use this method to decide if we can use the methods aware of the epoch.
@jsoriano not sure if this can be achieved with the current implementation of GetOffset
No, we would need to forge our own request as we do to request partition offsets to the leader. Or we could contribute to Sarama the support for these versions. 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
@@ -43,6 +43,10 @@ | |||
type: keyword | |||
description: custom consumer meta data string | |||
|
|||
- name: consumer_lag | |||
type: long | |||
description: consumer lag for partition/topic |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
probably worth it explaining what this is, as an important metric: the difference between the partition offset and consumer offset
Signed-off-by: chrismark <[email protected]>
Signed-off-by: chrismark <[email protected]>
@jsoriano, @mtojek , @exekias thank you all for reviewing! Almost everything is now addressed. @jsoriano regarding some special points:
Let me know what you think! |
Regarding @ChrsMark 's last comment - this PR is already medium sized one, I'm for pushing refactoring and dashboards to two next independent PRs. Thanks for addressing comments. LGTM! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, dashboard and further refactors can be left for future changes.
Failing tests are irrelevant and already addressed on #14849. |
(cherry picked from commit 23aaf5c)
This PR adds
consumer_lag
field inconsumergroup
metricset. This is calculated by subtracting groupOffset from partitionOffset for apartition-topic
pair.partitionOffset is retrieved from the cluster directly using https://github.com/Shopify/sarama/blob/afedecade3c6d8e99ab6dfeeea7814bf800b90a4/client.go#L62
May resolve_ #3608.
Signed-off-by: chrismark [email protected]